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ABSTRACT 



A svsteni and method for managing security incidents in a 
computing environment uses adaptive feedback to update 
security procedures in response to detected security inci- 
dents. Accordingly, the system and method is capable of 
deli uing security procedures, which can include one or more 
policies, and implementing these security procedures on one 
or more computing systems in the computing environment. 
Hie svstem and method monitors activities in the environ- 
ment and delects security incidents using the implemented 
security procedures. When a security incident is detected, 
the security procedures are updated in response to said 
detected security incident and implemented on one or more 
systems in the computing environment. 
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ADA1M1VK FKKDKACK SECURITY SYSTKM 
AND MKTHOI) 

MAC KG ROUND OI-THE INVENTION 

1. Field of the Invent ion 

'Pic present invention relates generally to computing 
environment security. and more specifically, to a system and 
method for adapting security procedures based on comput- 
ing environment activity. 

2. Related Art 

Since the earliest days of computers, the multi-user envi- 
ronment has been recognized as one in which efficiencies 
can he gained by allowing one or more computing resources 
to be shared among a plurality of users. Even in the 
contemporary world of personal computers, a plurality of 
users are typically networked or otherwise connected 
together to allow resource sharing. 

One simple example of multiple users sharing resources is 
a networked computing environment. In the networked 
computing environment, several computers or workstations 
are interconnected via one or more local or wide area 
networks (LANs or WANs) to allow the users to share 
network resources. In the networked computing 
environment, users can share network resources such as 
printers, modem pools, storage space, files and other 
resources. Users can also communicate with one another and 
share tiles electronically via local and remote e-mail. 

for as long as there have been multi-user computing 
environments, there have been concerns regarding the secu- 
rity of such environments. Early security efforts were quite 
simple by today's standards and were often limited lo 
point-of-entry security techniques such as requiring a valid 
user name and corresponding password. Hierarchical struc- 
tures were implemented to control access to certain files or 
operations based on a user's access level. 

However, as users became more sophisticated, chinks in 
the armor of these basic security efforts were quickly uncov- 
ered. Ill-motived users of all ages known as "hackers"' 
quickly demonstrated the weakness of the minimal user 
name nassword security techniques by breaking or "hack- 
ing" their way into numerous high-profile and or sensitive 
computing environments. In response, system developers 
increased security measures. This increase in security mea- 
sures was matched by corresponding advances in hacker 
techniques. So has the relationship between computer, or 
network, security administrators and hackers continued. 

Access of computing resources by unauthorized hackers 
from the outside is not the only security concern. Also of 
concern are authorized users attempting to operate beyond 
the scone of their user authority. In many systems, there are 
certain tiles or resources for which access is restricted, or 
certain admlnis'.ralive or other operations which can oniy he 
performed hv sys;c:n administrators. Also, where disk space 
i*. snared, users ir.ay not '.-e granted access to ccr'.am tiles o( 
other users. Iky mkI :hesc specifically restricted i pcr:ttioi>, 
i:kiv n*av v ecru, in ;.c.ivitics .if authorized users thai may 
be deemed inappropriate, or may be indica'.ive of inappro- 
priate activities, for example, a user accessing and copying 
a larue i: tinner .1' Lies nay indicate that the user is attempt - 
inc tc- abscond with important proprietary information. 
Thus, - he security concerns include ciVcctivcly restricting an 
authorized user to have access to files or lo perform opera- 
tions within his or her authority. 

SUMMARY Ol* NIL INVENTION 

The present invention is direded toward a sys'.cm and 
method for providing enhanced security features to a com- 
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puling system such as, for example, a networked computing 
environment. According to one aspect of the invention, a 
security policy system allows the creation and implementa- 
tion of one or more security procedures. These procedures 

5 can include, for example, audit policies, collection policies, 
detection policies, and security policies. 

An audit policy is defined and implemented in a net- 
worked computing environment to define or identify activi- 
ties of, or occurrences from, a user, or group of users, to be 

i ( ) audited. The auditing performed can include monitoring the 
networked computing environment for the occurrence of the 
ide nlilied activities tor the users or groups of users. The 
auditing can also include logging the occurrences of audited 
events. In one embodiment, the occurrences of audited 
activities or events are recorded in one or more event log 
files. 

A collection policy identities the frequency with which 
audited data, or events, are collected and provided to a 
detection subsvstem. The collection policy sets forth the 
schedule by which audited events are collected from the 
auditing engine and provided to a detection engine. 

A detection polic\ defines how the audited activities are 
analyzed to detect a security occurrence. "Hie term security 
occurrence is used lo refer to the occurrence of: one or more 

*" N instances of an actual or attempted security breach; a poten- 
tial security breach: suspect, unauthorized, or abnormal 
activity in the networked computing environment; or out- 
of-the-ordinary activities or a predefined condition which 
may indicate a security breach or unwanted activity is being 

" ; ° attempted. In one embodiment, the detection policy can 
identify threshold sellings, trigger levels or ranges for the 
audited activities so that security occurrences can be iden- 
tified from the collected occurrences of audited activities. 

A securitv policy defines the security practices of one or 
more resources in the computing environment, for example, 
the security policy may define criteria such as the number of 
unsuccessful logon attempts allowed before a system is 
shutdown or a user's ID is invalidated, the aging of 
passwords, the size and type of passwords, the level of 
access granted lo guest users, and so on. 

In a computing environment such its, for example, a 
networked computing environment, a security or system 
administrator can deline the initial security procedures for 

4 < the computing environment . "These can include a definition 
ol one or more of audit policies, security policies, detection 
policies and collection policies. 'Hie definition is usually 
made based on the level ol" security desired for the network, 
considering the overhead associated with monitoring net- 

c, \\ork activities and detection of security occurrences. 

According tc ;-nc aspect of '.he invention, when a security 
occurrence is delected, one or more of the policies that make 
un :he security procedures can ; v modified and the modified 
policy or policies implemented in the computing etiviron- 

^ ir.ent. According t» '.his adaptive feedback aspect of l he 
i nve r. tit n. pol.c.cN can be adoptively updated and the 
uncia.ed policies implemented in the network. The updates 
can be made ba>cd u security concerns ^.r procedures in 
general, or ba>ed on ;.n identification of the user or users 
associated with t ne ,;r mure delected securiiy occurrences. 

Additionally, inlorma'.ion relating to the type of security 
occurrence detected can ! v used in updating and implement- 
ing the one or more policies in the computing environment. 
In one embodiment, '.he updates lo the policies that make up 

f»5 the securiiy procedures can he fully automated such that no 
intervention by an administrator is required. Alternatively, 
alerts lo an administrator can be provided such that an 
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administrator can he asked 10 provide feedback or other 
input to control, monitor or approve the updating of die 
sec ii ri ly procedures. 

hi another embodiment of the invention, a security or 
nelwork administrator can establish predefined levels ot 
security upgrade based on the security occurrences detected. 
In (his embodiment, when the security occurrence is 
delected, one or more of the security procedures are updated 
to a higher predefined level. According to yet another aspect 
of the invention, each of the individual security procedures 
can be set to have a stepwise or incremental increase in 
securitv level. Security procedures can also be set to increase 
to a maximum defined security level upon the detection ot 
a securitv occurrence. Hie monitoring, delecting, and policy 
updating can continue to occur in a cyclical fashion, depend- 
ing on the circumslances surrounding the security 
occurrence(s). until some predefined limit or limits arc 
reached, or until an administrator or other authorized per- 
sonnel intervenes. 

One advantage of the invention is that security N 
procedures, including one or more of the associated policies, 
can be updated automatically upon the detection of a secu- 
rity occurrence. Such an update can be accomplished at a 
predetermined level and without user intervention. 

Another advantage of the invention is that the updates to :5 
the policies that make up the security procedures can be 
determined based on an identification of the user or users 
associated with delected security occurrences. The updates 
can also be made based on an identification of the types of 
activities indicated by the detection of the security occur- 
rences. As such, security procedure updates and implemen- 
tations can be made based on actual or perceived needs and 
tailored to specific occurrences. As such, system perfor- 
mance degradation, which would otherwise occur as a result 
of shifting to a maximum security procedure, can he 
avoided. 

According to another aspect of the invention, custom 
audii policies can be defined to identify one or more u>ers or 
groups of users, one or more activities or occurrences 
associated with ihe identified users or groups of users, and 
other activities or occurrences to be audited. One advantage 
uf the custom audit policy is that wild card designators can 
be used :o allow activities or occurrences relating to par- 
ticular tiles or ly pes of tiles to be I racked across a number ol 
diverse computer architectures, irrespective of the specific 
tile structure implemented thereon. 

In this document, the term "user" is used to refer to one 
or more users or groups of users, whether authorized or 
unauthorized. The term "security administrator"' refers to a 
user having rights to oversee or adjust the Securiiy aspects ot 5 
all or part of :he computing environment and can include, for 
example, a svsteni administrator or a network administrator. 
IJKIEE DESCRIPTION OF NIL DRAWINGS 

FIG. I is a : Mock diagram i'.li.'stratir.g an example :iet- ; 
worked compuir.g environment acct-rding to one cmhodi- 
r.icn: o:' the mveir.ion. 

2 is an operational :lo\v diagram generally i'.luslrat- 
ini: the creation and implementation of security procedures 
in a networked compiling environment according :o one 
embodiment of the invention. 

I IC*.. 3 is block diagram iliusira'.ing an example imple- 
mentation of an audit policy in accordance with one embodi- 
ment of the i nven: ion. 

FIG. 4 is a diagram illustrating an example user interface <- 
that can be provided to defmc an audit policy in accordance 
with one example Implementation of :he invention. 
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FIG. 5 is a diagram illustrating an example user interface 
that can be provided lo deline a file audit of an audit policy 
according to one example implementation of the invention. 
FIG. 6 is a diagram illustrating an example user interface 
-" , that can be provided to define a registry key audit according ^ 
to one embodiment of the invention. 

FIG. 7 is a diagram illustrating an example user interface 
thai can be provided to define a collection policy according 
to one embodiment of the invention. 
10 FIG. 8 is a diagram illustrating an example user interface 
that can be provided to define a detection policy according 
to one embodiment of the invention. 

FIG. 9 is a block diagram illustrating an example inter- 
action of various policies that can lie implemented lo make 
up a security procedure, the assessment of data in accor- 
dance with securiiy procedures, and updating securiiy 
procedures, in accordance with one embodiment of the 
invention. 

FIG. 10 is an operational ilow diagram illustrating an 
example process for implementing and updating policies in 
accordance with one embodiment of Ihe invention. 

FIG. 11 is an operational (low diagram illustrating an 
example process for updating security procedures in accor- 
dance with one embodiment of the invention. 

FIG. 12 is an operational How diagram illustrating a 
manner in which one or more policies that make up the 
securitv procedures can be updated in accordance with one 
embodiment of the invention. 
* ; ° FIG. 13 is a block diagram illustrating an example archi- 
tecture of a security system according to one embodiment of 
ihe in ven I ion. 

FIG. 14 is a block diagram illustrating another example 
architecture of a security system according to one cmbodi- 
° ment of the invention. 

FIG. 15 is a block diagram illustrating a general purpose 
computer system, including examples of computer readable 
media for providing computer software or instructions, 
according to one embodiment of the invention. 

40 

DETAILED DESCRIPTION OF THE 
FRET-ERRED EMBODIMENTS 

1. Introduction and Overview 
The present invention is directed toward a system and 

45 method for providing enhanced network security. According 
to the invention, several enhanced computing environment 
securitv aspects can be provided individually, or in combi- 
nation. According to one aspect of the invention, a system 
and method are provided for creating security procedures for 
< a computing environment. According to another aspect of 
the invention, a system and method are provided for allow- 
ing adaptive feedback in the creation and implementation of 
a security system for a cor.ipir.ing environment. 

(ieneraliv speaking, in one embodiment of the invention. 
5 secjriiv procedures fur ;i com puling environment can be 
created and implemented within the computing environ- 
ment, file secari'.y procedures may tie line, for example, 
audit policies, collection policies, security policies, and 
detection policies. If :he -Astern de'ermines that a potential 
• securi'.v preach is attempted or has occurred, the currently 
implemented policy or policies are updated and the newly 
updated policies implemented. 

2. Example Environment 
Before describing the invention in detail, it is useful to 

5 describe a simple example environment in which the inven- 
tion can be iniplemeiKed. One such example environment is 
a networked compiling environment comprising a plurality 
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of computers, workstations or other processor-based sys- 
tems interconnected hy a communications interface such as, 
lor example, a computer network or other interface. 

RG. 1 is a block diagram illustrating an example net- 
worked computing environment according 10 one embodi- 
ment of the invention. Networked computing environment 
100 according lo this example includes a plurality of net- 
worked computers 104 interfaced via a network ION. Net- 
work 10X can be implemented utilizing one or more local 
area networks (LANS), wide area networks (WANS) or 
oilier connection techniques or communication technolo- 
gies. Note that one or more computers 104 can also be 
interfaced to network 108 via an external dial-up commu- 
nication link, or other external link. Although not illustrated, 
die networked computing environment can also include 
network resources such as printers, scanners, modem pools, 
storage devices and other resources. 

Hie invention is described herein in terms of this example 
networked computing environment 100 and an example 
application in this example environment. Description in :o 
these terms is provided for ease of discussion only. After 
reading the description herein, it will become apparent to 
one of ordinary skill in the an that the present invention can 
be implemented in any of a number of dilVereni computing 
environments. 

.V Computing Environment Security System 

In one embodiment of the invention, one of the computers 
104 in the networked computing environment 100 is desig- 
nated as performing network security -related functions. In 
the example illustrated in RG. 1, this computer 104 is M) 
illustrated as a security console 10415. In one embodiment, 
security console 1041) is responsible for performing security 
operations related to the security of the networked comput- 
ing environment 100. The security operations can include, 
for example, operations such as preparing and updating :-5 
seen r it v procedures and administering the security monitor- 
ing on the network. 

Computers to which the security procedures are applied 
art referred to in this document as target computers 104 A, 
or target workstations. It is uses of and activities conducted -w 
through target computers 104A that are monitored for secu- 
ritv occurrences. Security procedures can also be applied to 
security console 104B. In other words, security console 
1041* can aiso be a target computer. 

In vine embodiment, the security procedures can include, 45 
for example, one or more of security policies, collection 
policies, detection policies and audit policies. The security 
console 104H can also perform the adaptive feedback 
operations, including updating the security procedures based 
on security occurrences. • > " 

l:i or.e emvd ime.it, sec:iri:y console 104li is a dedicated 
machine, devote J in performing security-related operation. 
Ir. a:i lucrative embodiment, security ans.*le HMIi can 
al*. be tr.ili/ed :o perform other coir p.ithg functions i:i 
networked cor.ipm.ng environment 100 Ak- ii"te l:iat. .is 55 
describee lvl"W. cer.ain f.iu.c'.ion- . f the invention car. be 
performed on or.e or more of the plurality of computers *»r 
uv'ik.vali*Mi- 104 .ii addition u- a .security cons-tie I04li. It 
is important to r.o;e thai security console 104 U can also be 
a target computer MM A. ' ,l 
i. Creation of Seen r it > Procedures 

As slated above, on aspect of tne inv ention is the crea'.ioii 
of securitv procedures for ihc compuiing environment. RG. 
2 is an operational How diagram generally illustrating '.he 
creation and implementation of security procedures in a ->r 
conr.u.'lir.g environment, such as networked computing envi- 
ronment 100. according to one embodiment of the invention:. 
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Referring now to R(i. 2, in a step 204, an administrator 
defines security procedures on security console 104H. Secu- 
ritv procedures can include one or more security-related 
policies implemented on the network. Examples of such 
5 security-related policies can include, for example, audit > 
policies, securitv policies, detection policies and collection 
policies. 

Audit policies, which at a general level are generally 
known in networked computing security, are policies that 
to deli no activities to look for or monitor in the networked 
computing environment. In other words, the audit policy 
defines what activities of a user or users are to be audited. 
In this regard, audit policies can be thought of as defining or 
specifying data to be gathered. Audit policies can define 
< users, actions and objects, when denning data to be gathered. 
An audit policy is perhaps best described by way of 
example. In one example, an audit policy may be used to 
define or delineate one or more users for whom data should 
be iia the reel, and may specify operations of those users for 
which data should be gathered. 

As just one specific realization of this example, an audit 
policy may be implemented to define data to gather on one 
or more users modifying an executable tile. Another specific 
example may be lo define the auditing of activities by certain 
users attempting to access certain files for which they do not 
have access privileges. While these examples generally 
illustrate the concept of audit policies, these examples 
should not be interpreted to limit the definition thereof. 
Audit policies are described in greater detail below. 

In a step 208, the security procedures defined in step 204 
are implemented in the compuiing environment. In one 
example implementation, agents 112 running on target com- 
puters 104A gather data in accordance with the audit policy. 
Tor example, agents 112 on target computers 104A may 
gather events on any read, modify and write operations, or 
attempted ope rat it ins of one or more users on target com- 
puters 104A as specified in the audit policy. In one 
embodiment, as discussed below, collected data on activities 
or operations is logged in an event log file. In one 
embodiment, the event log file is maintained locally at target 
computers 104 A. In alternative embodiments, the event log 
file is maintained at securitv console 104U, or .some other 
independent network entity. In one embodiment, agents 112 
on ;arget computers 104 A can also monitor the operations of 
users on target computers I04A in accordance with the 
implemented procedures. However, as discussed below, 
monitoring and detection are preferably performed at a 
security console 104B. 

At periodic or other time intervals, data gathered in one or 
more lo^ tiles is collected in a da l a collections step 212. A 
co|'.ec::o:i polic\ can be implemented lo define I he collection 
times or o:her collection, parameters. 

In a siep 216. the da: a collected in step 212 is analyzed. 
In ..nc. embodiment, he .ni:.!ys.s is performed by agents 112 
inipieille:ili:ic a delec'.ioii p. Iic\. in this step. *.he agents 112 
ana I we one <w m,nv c^eir.s in ir. one or more even: log flies, 
ll'.e data a:i;.lysis c;.n be performed ^y agents 112 on target 
ir.achin.es HMAorhy .tgur.s 112 on a securit\ console 104H. 
In ll'.e da'.a analvsis step, occurrences logged In the event log 
file are reviewed, will respeCl to the detection policy, lo 
determine whether any security breaches have been 
allemp;ed or have occurred, for example, the data analysis 
step mav look at patterns for particular users, or look to 
determine whether a lumber of occurrences has exceeded a 
predefined limit. 

If the data analysis determines thai a security incident has 
occurred, or was likely attempted, a security response action 
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may be taken. This is illustrated hy steps 220 and 224. If, on 
the other hand, it is determined that a security incident has 
not been commuted or attempted, the data collection and 
analysis sieps continue as illustrated by How line 262. 

"Hie security response action taken in step 224 can > 
include, for example, shutting down a target computer 104A, 
logging oil* a particular user who is suspected of committing 
or attempting a security breach, minimizing access granted 
to a suspected user, or other appropriate or desiied action. 
However, in one embodiment or in certain applications of 
the invention, it may not be desired or desirable to lake such 
immoderate steps immediately. Thus, m one embodiment, 
the security response action taken in step 224 can include a 
step of updating the security procedures defined in step 204, 
and implementing these updated procedures. 

The updated procedures can be implemented to perform, 
for example, a more thorough or increased audit of the user 
or users involved in the security occurrence, or otherwise 
suspected of committing or attempting to commit a security 
breach, l or example, in one application of the invention, 
where a user is suspected of committing or attempting to 
commit a security breach, the audit policy may be amended 
to instruct agents to delect and log every read and write file 
operation performed or attempted by thai particular user or 
group of users. Thus, in this manner, a more complete record 
of the user's or users' activities can be made and a belter 
assessment of the motives behind those activities. 

Of course alternative applications can be implemented 
where other changes are made to the security procedures to 
obtain more information about the suspect user or to further 
restrict his or her access or activities. Generally, the audit 
policv mav be updated to obtain more information about the 
user's activities on the network, the collection policy may be 
updated to collect user events more frequently, and the 
securitv policy may be ■'lightened" via the detection policy 
to have a lower threshold or to more strenuously analyze and 
llati suspect activities. The adaptive feedback system can 
simiiarW be implemented to allow "relaxation" of the secu- 
ritv procedures based on recent network activity. In one 
embodiment, however, such relaxation is not permitted to 
occur automatically, and requires administrator approval or 
manual relaxation. 
5. Security Procedures 

As described above, one pari of a security procedure can 
include audit policies. Audit policies, brielly introduced 
above, are discussed now-' in greater detail. FIG. 3 is block 
diagram illustrating an example implementation of an audit 
policv in accordance with one embodiment of the invention. 
In the example embodiment illustrated in FIG. 3, the audit 
policv 300 includes a system audit 304, an object audit 324, 
and a registry key .iiidit 334. As would be understood by one 
of ordinary skill in tne ar: after reading this description, 
addi:ioiial or alternative audit areas car. : *>e Jc lined and 
implemented. 

According u one aspect of the invention, syskir. audit 
304 def.nes an *.vent audit 30S that ai.dils one or more 
ideir.iliec. everts . cc-.irri:ig if. the svMem. Object a -.id it 324 
can .ncbde identification of one or more objects 322 to 
which the audit per; a ins. a user or tisers 326 whose activities 
shouk: be audited w ill: respect to identified objects, and 
operations 32N performed or attempted on the identified 
object or objects. ( hie example of an object is a I tie. although 
other objects can -x- identified for audit. 

ReiMSirv key aticit 334 can include an identification of a 
list 332 of one or more registry keys to be audited, a user or 
users 336 whose activities should be audited with respect to 
identified flies, and operations 33S performed or attempted 
on the iden lifted registry keys. 
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FIG. 4 is a diagram illustrating an example system audit 
screen 400 in accordance with one example implementation 
of the invention. Referring now to FIG. 4, system audit 
screen 400 de lines a plurality of audit events. In accordance 
with this example implementation, system audit policy 304 ^ 
can conduct or define audits to determine the occurrence of 
the success and or failure of certain activities. Examples of 
these activities according to the illustrated embodiment are 
outlined in window [xniiou MH. included in the illustrated 
example are log on and log oil events, tile and object access 
events, use of user rights events, user and group manage- 
ment events, security policy changes, restart, shutdown, and 
system events, and process tracking events. Additionally, the 
administrator defining the audit policy may choose not to 
audit any events as illustrated by a DO NOT AUDIT button 
15 or selection 412. 

Returning now to FIG. 3, an object audit 324 can include 
an audit of objects 322. users or groups of users 326, and one 
or more operations 32S. One example implementation of 
creating an object audit is illustrated in FIG. 5. In the 
:o exampfe illustrated in FIG. 5, a display screen for imple- 
menting a file audit 324 of an audit policy according to one 
example implementation of the invention is illustrated. File 
list window portion 504 provides a list of tiles that can be 
selected for auditing. One or more computer directories can 
25 be scanned to display in window portion 504 a list of files 
that are candidates for potential auditing. Add, edit and 
remove buttons 509 can be used to create and modify a list 
of files to be audited. 

In one embodiment of the invention, a wild card such as, 
?0 for example, an asterisk (*) can be used to facilitate file 
selection. For example, in some networked computing envi- 
ronments it is foreseeable that a particular tile desired to be 
audited may not reside in the same directory in the one or 
more target computers 104A. As such, a wild card feature 
15 allows thai tile to be specified regardless of its path or 
directory in each of the target computers 104A. As an 
additional example, if it is desired to identify for audit all 
executable tiles (e.g.. files having the .exe extension), a wild 
card such as \exc can be specified to identify all executable 
41) files. Hie wild card can be any character designated as being 
a wild card, but is preferably an asterisk (*). The wild card 
can be used as a wild card in one or more characters of file 
names, or as a wild card in one or more locations in the 
directory or tree structure of a file, or both. 
45 Groups users windows 50S can be utilized to select or 
identify one or more users or groups of users as targets for 
the audit. In one embodiment, one or more predefined 
groups can be created to facilitate identification of users. In 
the example illustrated in FIG. 5, a single group titled 
>■> ••FVFRYONU" is illustrated. Although the functionality is 
not illustrated on the screen diagram of FIG. 5. the func- 
lionalilv can be provide;: in one embodiment to allow the 
administrator to create and edit custom groups. 

The o:\ralions 32N that can be edited in the example 
55 implementation of FIG. 5 are illustrated in window portion 
512. Iti this example . tries*, include success and or failure of 
a ad operations, write operations, execute operations, delete 
operations, change-permission operations, and lake- 
ownership operation^. 'I litis, as illustrated by the example 
implementation of FIG. 5. the administrator can specify 
particular files or groups of files, users or groups of users, 
and operations or group of operations lor audit purposes. 
Additionally, the administrator can select whether to replace 
auditing on subdirectories, and whether to replace auditing 
i5 on existing files as iilusiraled by selection boxes 517. 

Returning now to FIG. 3. registry key audit 334 can 
include registry key lists 332, users and or groups 336, and 
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operations 338. FIG. 6 is a diagram of a computer screen 
illustrating an example implementation of a registry key 
audii according, to one embodiment of the invention. Reg- 
istry key list window portion 604 allows a selection of one 
or more registry keys for the system of interest. Add, edit 
and remove but ions 609 can be used to update and create the 
registry key list. Similar to the rile audit policy illustrated in 
l ; IC). 5, groups, users window 608 allows selection of one or 
more users or groups of users for the registry key audit. Add 
and remove buttons 6 10 can be used to create and modify the 
list. Operations thai can be selected for registry key audit in 
the example implementation can include success and or 
failure of a query value, a set value, a create sub key, 
enumerate sub keys, notify, create link, delete, write, dis- 
cretionary access control (DAC), and read control. 
Additionally, the administrator can select whether to replace 
auditing on existing sub kevs as illustrated bv selection box 
614. 

FIGS. 3, 4, 5, and 6 described above provide an example 
implementation for creating and administering an audit 
policy 300 in accordance with one embodiment of the 
invention. After reading this description, it will become 
apparent to one of ordinary skill in the art how alternative 
implementations for audit policies can be utilized in accor- 
dance with ihe present invention. These alternatives can 
include, without limitation, alternative system events for 
auditing, alternative objects for auditing, alternative screen 
layouts, and alternative features/Options provided. 

Collection policies are policies that set forth the specific 
details on how or when the auditing information is to be 
collected. As stated above, the information from the per- 
formed audits is placed in one or more event log files. In this 
example, the collection policy may indicate a collection 
schedule for collecting audit information from the one or 
more event log riles. One overall schedule can be provided 
for all of the event log tiles, or individual event log files or 
subsets of event log files can be established to provide 
llexibilitv. in one embodiment of the invention, the collec- 
tion policy provides a 24 hour. 7 day a week calendar that 
can be used to establish a collection schedule. 

FIG. 7 is a diagram illustrating an example implementa- 
tion for a screen layout used by an administrator to define the 
collection policy. In the illustrated example embodiment, the 
calendar provides a screen having 24 boxes 712 for each 
daw one box 712 for each hour. Hie administrator can use 
a mouse or other pointing device to select one or more boxes 
to identify a collection lime. For example, the administrator 
mav choose to collect the audit data from all systems twice 
dailv, once at A PM and once at 12 noon. The administrator 
may identify a dilVerent collection schedule for each day, or 
may identify diflereiil schedules for weekdays and week- 
ends. 

In one embodiment, the administrator can click on a box 
712 to select that box 712 as a collection lime for that day. 
Alternative! v. the administrator can double click on a lime to 
select everv da\ at that time, or double click lmi ,i day to 
select evei v time for that day. Additionally, the user can click 
and drag the pointer across several squares 712 to toggle a 
croup or block of squares on or oT 

Regard iess of the tool provided or screen layout used to 
select collection days and limes, ihe collection policy estab- 
lishes when the audited data is lo be collected by the security 
svstem. As would be apparent to one of ordinary skill in ihe 
art after reading this description, alternative collection tech- 
niques can be employed to allow collection of audit data at 
desired times or intervals. 

The detection policy can be used lo identify I ha I a security 
occurrence has occurred. In one embodiment, ihe detection 



policy is used to establish thresholds or limits which, when 
reached, trigger an alarm or other condition indicating that 
a security breach, attempted security breach, or other net- 
work security condition has occurred or is occurring. For 
example, the detection policy may be established to rai.se a . 
Hag after a predetermined number of unsuccessful log-in 
attempts for a particular user name. As this example 
illustrates, thresholds, limits or ranges can be sei for one or 
more of the plurality of audit parameters to raise Hags, which 
potentially could result in an upgrade or update of the 
security procedures. 

The security policy can include security settings or 
values, which define the security of the system. The security 
policv can define parameters such as, for example, minimum 
and maximum password age, minimum and maximum pass- 
word length, password uniqueness, account lockout, reset 
account time frames, lockout durations, forced logouts, user 
log ons lo change password, and other security policies. 

FIG. 8 is a diagram illustrating an example implementa- 
tion of a window for implementing a detection policy 
according to one embodiment of the invention. In the 
example illustrated in FIG. 8, a plurality of activities or 
activity tvpes are listed in window portion 804. Check boxes 
814 are provided so that one or more of these listed activities 
can be selected by ihe administrator. Check boxes 816 allow 
selection of all or none of the listed activities in a single 
click. Table 1 is a listing of several examples of activities 
that can be included as activities to watch in implementing 
a detection policy. Also illustrated in the example provided 
in FIG. 8 is an activity signature properties window 820. In 
this window the activity priority can be set (HIGH, 
MEDIUM, or LOW) as illustrated by click down window 
822. Also illustrated in this example, the response to a 
detected activitv can be set in click down window 824. In 
one embodiment, these selections can include as responses 
thai can be selected : no response, log olV user, shut down 
svstem, disable account, or upgrade procedures. 

In area 828 the administrator can select how he or she 
should be noli lied. The example illustrated includes check 
boxes for e-mail, pager, and SNM1' (Simple Network Man- 
agement Protocol). Also provided are windows to enter the 
administrator's e-mail address and pager number where 
a ppropriate. 

Also provided in the illustrated example is a window 
portion 829 listing tiles associated with a selected activity. In 
this example, when the cursor is used to highlight an activity, 
a list of Ihe riles or objects generally audited lo detect an 
occurrence of the highlighted activity appears in window 
portion 829. Fdit buttons 830 allow the lisi of riles or objects 
to be edited. 

Thus, in summary, ihe audit policy dictates the types of 
data and occurrences that are to be monitored and collected: 
the collection policy dictates the frequency and amount of 
collection; the detection policy sets ranges, thresholds, or 
iriexcr levels lo line! a network security occurrence; and the 
.security policy provides sellings for handling various secu- 
rity procedures and occurences. The examples described 
above with reference to the illustrated screen layouts are 
provided : iv way of example only and not iimilat ion. After 
reading ihi.s description, i: \wll become apparent lo one of 
ordinary skill in the art that alternative implementations are 
possible, and thai the invention is not limited to the 
examples disclosed herein, 
o. Updating the Security Procedures 

As staled above, when unusual or suspect activity is 
detected in ihe networked com puling environment, one or 
more security procedures can be updated and implemented 
in the network. 
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The manner in which ihe one or more security procedures 
are u pel a led and implemented is now discussed in more 
detail in accordance with one or more embodiments of the 
invention. When analysis of the gathered and networked 
information indicates a security occurrence (i.e., one or more 5 
users, or an unauthorized user has performed a security 
breach, or apparently attempted a security breach or other 
unauthorized activity), the security procedures can be 
updated manually, automatically, or by a combination 
thereof. In one embodiment of the invention, the security 10 
procedures can include audit policies, collection policies, 
detection policies, and security policies. 

TIG. 9 is a block diagram illustrating the interaction of the 
various policies that can be implemented to make up this 
securiiv procedure the assessment of data in accordance 15 
with security procedures, and the updating of security pro- 
cedures in accordance with one embodiment of the inven- 
tion. FIG. 10 is an operational How diagram illustrating the 
process of implementing and updating the policies according 
to one embodiment of the invention. Referring now to FIGS. :o 
9 and 10, in this example embodiment, the security proce- 
dures include an audit policy 904, a collection policy 912, a 
detection policy 916, and a security policy 9 IS. In a step 
1044, audit policy 904, collection policy 912 and detection 
policy 916 are implemented within networked computing 25 
environment 104) to monitor and handle security-related 
items. In one embodiment, audit policy 904 provides an 
application running on one or more target systems 104Ato 
perform the identiJied audit. 

In accordance with the audit policy specified for a target :-o 
104 A, one or more event log files 908 are generated and 
recorded indicating the various audited activities occurring 
within the target 1 04 A. This is illustrated by a step 1046. In 
one embodiment, event log file 908 can be kept locally at 
each target 104A to collect records for that target 104A. ^5 
Alternatively, one or more event log riles 908 can be kept 
centrally such as, for example, at a security workstation 
104B, or at one or more targets 104A. 

In a step 1048. the implemented collection policy 912 
results in the collection of the records in event log files 90S 40 
at the scheduled intervals. The collected records are pro- 
vided to the seen rit v svsiem lor analysis. This analysis is 
referred to as a security assessment 924. In a step 1052, the 
security assessment is performed based on the audited 
activities that have been recorded in event log liles 908. The 45 
securiiv assessment is performed in accordance with the 
detection policy or policies 916 established for the network, 
or for that user or workstation. 

When security assessment 924 determines that an actual, 
attempted or potential security breach has uccurred or is 5*- 
occurring, one or more policy upda'.es 92S are made u i one 
or more of the audi: policy 904. collection policy 912 and 
detection policy 916. This is ilhsiraled by a <lep 1054. 

FIG. H is an operational ll"W digram illustrating an 
example vf how - .he security procedures can be updated in 
accordance with o:x embodiment of the invention. In a step 
1 104. the user or ej'oi.p of users associated witn the potential 
se-ctirtiv breach are identified. As described, this identifica- 
tion can come from the audited information i:i which activi- 
ties for a user or groups of users are tracked and recorded 
accordion to the defined user or groups of users. 

In a step HON. the type of breach or potential breach is 
identified, for example, there may be one or more activities 
thai have been delected as a result of the audited events. In 
ihisstep. the t\pes of activities are identified and it possible, ;>5 
grouped to indicate the type of breach attempted or effected, 
for example, the -.>ccurreiice of several failed log in attempts 
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from one or more user names may indicate that one or more 
individuals are an em p ling to hack their way into the system. 
As another example, the occurrence of a large number of 
open and copy operations from a particular user may indi- 
cate that that user is attempting to copy a large number of x 
files in preparation for stealing information from the net- 
worked computing environment KM). 

Note lhat in one example described above with reference 
to FIG. «S, an activity identified in the detection policy is 
detected as having occurred. In this example embodiment, 
the type of security occurrence is inherently identified. 

In a siep 1112, a security administrator or other identified 
network administrator is informed of the potential or actual 
security breach. Preferably, this information includes the 
identification of the user or group of users associated with 
the potential breach as identified in step 1104, as well as the 
tvpe of security occurrence as identified in step 1108. In one 
embodiment, the security administrator can recpiest and be 
provided with a listing of the appropriate records in the event 
log file that were used in arriving at the information obtained 
insteps 1104 and 1108. 

In one embodiment, these records can be provided in 
accordance with the techniques described in co-pending 
U.S. patent application Ser. No. 09,0X0,635, titled "EVI- 
DENTIARY TRAIL SYSTEM AND METHOD/' tiled on 
Mav 18. 1998, and which is incorporated by reference herein 
as if set forth in full. 

In a step IU6, the security procedures including one or 
more of the associated policies can be updated based on the 
user identification and type of occurrence as indicated in 
steps 1104 and 1108. 

FIG. 12 is a diagram illustrating the manner in which one 
or more policies lhat make up the security procedures can be 
updated in accordance with one embodiment of the inven- 
tion. As previously stated, the updates lo the one or more 
policies can be effected automatically, or upon intervention 
of the security or network administrator. In one embodiment, 
in which the updates occur automatically, Ihe security or 
network administrator can preselect or predefine a level of 
updates that are lo occur upon the detection of a security 
occu rrcnee. 

In a step 1204. the security policy for the network can be 
updated and implemented for the identified user or group of 
users, for one or more computers or workstations in the 
computing environment, or for the entire network. In one 
example provided above, it may be determined that one or 
more unauthorized users are attempting to hack into the 
system, In this example, ihe security policy may be updated 
to increase the entrv security procedures for the entire 
network. 'IT)is can include, for example, decreasing the 
number of allowed unsuccessful log on attempts, and 
increasing the lime period before the number of unsuccess- 
ful attempts is reset. 

Ir. another example, a user may be attempting to perform 
unauthorized operations, such as access restricted files. In 
Ibis example, the security procedure may be updated to 
automatically log-off i;iat user, or to monitor thai user's 
activities more closely and more frequently. 

lr. one embodiment, the increase in ihe one or more 
policies of the securit\ procedures can be done in a step 
wise, iterative fashion as illustrated by block 1206. 
Alternatively, the increase can be set to transition immedi- 
alely lo ihe maximum security level as indicated by block 
I20N. For example, where a stepwise increase is selected, 
the level of security implemented by the security policy can 
be increased in a step-wise fashion to a higher level of 
security. In one embodiment, the step-wise increases to ihe 
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next level increments one or more parameters of the policy 
bv a predefined amount. 

In an alternative embodiment, a plurality of templates for 
one or more policies can be defined. The policy or policies 
are upgraded to a higher level by selecting and implement- 5 
ing a hitiher-level or upgraded template. In this embodiment, 
the securitv administrator, for example, can create the tem- 
plates as predefined security policies when configuring the 
security system. Thus, when a security occurrence is 
detected, the system can automatically transition to a des- 10 
ignated template, or the administrator can select an upgraded 
template to implement. 

When a security occurrence is detected, the policy is 
upgraded to the next level. If after I he pet! icy has been 
incremented to the next highest level of security, a security i> 
occurrence or occurrences are still occurring, one or more an 
additional increases can be implemented. This can continue 
unlit the maximum security policy settings are reached. 

Alternatively, the stepwise increases can occur for a 
predetermined number of steps, until the settings are :o 
defaulted 10 the maximum security policy sellings. 
Additionally, in one embodiment, at any lime the security 
administrator can intervene to increase or decrease the 
settinus, transition immediately to ihc maximum security 
policy settings, or to return to the minimum security policy ?5 
seiiinus. Tor significant security incidents, steps can be 
skipped and one or more policies immediately transitioned 
to the highest level. 

In addition to or instead of changes to the security policy, 
the audit policy can be changed as indicated by block 1214. *o 
Preferably, in one embodiment, the audit policy is changed 
only for those users or groups of users identified in step 1 104 
of FIG. 11 as being associated with the particular security 
occ u rre n ce id e n 1 i lie d . 

Hie audit policv can be updated to look at where those .-5 
activities related lo the type of occurrence identified in a step 
SOS, as illustrated by block 1216, or lo look at all activities 
associated with a particular user or groups of users as 
indicated by block 12 IS. As with updates to the security 
policy, updates to the audit policy can he set lo occur 40 
incrementally, or to automatically transition to the maximum 
settings such that all activ ities or all activities of a particular 
type or an identified user or groups of users can be audited. 
Intervention by a security administrator or network admin- 
istrator can be permitted in one embodiment to allow custom 45 
adjustments to be made. 

Additionally, or alternatively, the collection policies can 
be modified as illustrated by block 1224. The collection 
policies can be modified for all users, or just for the user or 
group of users identified in <lep S04. The co:lec:ion policies 5- 
can be increased in a stepwise fashion >uch that ihe collec- 
tion frequency is increased incrementally as il lustra led by 
block 1226. Alternatively, ihe collection policy can be 
modified to transition to >ome predefined maximum collec- 
tion: freipiency as illus;ra'.cd by block 122N, As is the case .-=5 
wi'.h security policv and audit policv updates, i:ilei'ven:io;] 
bv a security administrator or neiwork administrator can he 
perm. lied in one embodiment lo ailow custom ad;u>:nie:ils 
lo be made to the collection policy. 

Additionally or alternatively, the detection policy can be 
modified as indicated -.y block 1234. In one embodiment, 
modification of a deiec'.ion policy involves lowering :he 
threshold or :ricner levels for which a security occurrence is 
detected. As with other policy modifications, modification o! 
the detection policy can *v implemented in a s'.epwise -5 
fashion as illustrated by block 1236. or the modification can 
be i in mediately implemented to transit ton *.o the lowest 
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lh res ho Id setting as illustrated by block 1238. As with the 
other policy implementations, manual intervention or over- 
rides can be implemented by the security or network admin- 
istrator. 

(). Example System Implementations 

Although there are numerous architectures thai can be 
implemented to provide the security features of the present 
invention, two example implementations are described. T'KI. 
13 is a block diagram illustrating an example implementa- 
tion in accordance with one embodiment of the invention. 
Hie example implementation illustrated in FIG. 13 includes 
two modules, an audit module 1304 and a security procedure 
module 130S. In one embodiment, an audit module 1304 is 
implemented and running on each of the computers 104 in 
the networked computing environment, while security pro- 
cedure module 130S can be implemented on a dedicated 
security console 104K 

Audit module 1304 can includes a collection policy 1312. 
an audit policy 1314, a security policy 1316. an audit agent 
1320. and a local event log, 1324. Audit agent 1320 monitors 
and collects events and activities occurring in the network 
computing environment and stores records of these events 
and activities on local event log 1324. As described in detail 
above, security procedures, which can include the various 
policies, are used to define the security environment of the 
target 104A. Audit policy 1314 dictates the activities or 
operations audited and togged by audit agent 1320. Collec- 
tion policy 1312 sets for the collection schedule or interval 
for collecting logged events and providing collected events 
to the detection system. Security policy 1316 sets for the 
security parameters for a given target or for a given user. 

Security procedure module 1308 includes a collection 
agent 1340, a detection engine 1342 and a response service 
1344. In addition, policy editors 1332, 1334, 1336, and 1338 
are provided lo update the one or more policies that make up 
the securitv procedures. Collection agent 1340 collects the 
activities and events logged by audil agent 1320 and col- 
lected in accordance with collection policy 1312. 

A detection engine 1342 evaluates the collected events 
and activities to determine whether a security occurrence 
exists. For example, as described above, this can include 
monitoring activities to determine whether established 
threshold levels have been met or exceeded, whether activi- 
ties are occurring out of nominal ranges, or whether unau- 
thorized activities are attempted or performed. 

If a security occurrence is delected, notification is pro- 
vided to response service 1344. Response service 1344 
determines what corrective action is necessary and instructs 
one or more of ihe policy editors 1332-1 33S to update ihe 
policies and provide these .ipdatcs 10 ihe one or more audi! 
modules 1304 in the networked computing environment. As 
discussed above, ihc policies can be updated to mere men - 
lall\ increase '.he func:io;iali'.y defined by those policies or 
to implement :ho^- pol.c.es a: the highest level of security. 
Addi'.ionallv, an administrator such as a network adminis- 
trat; r 1 1 security administrator can be alerted when a secu- 
rity inciden: is delected This a.crl can be an audible alert or 
a uarn.ng :lashingon c.isp.ay screen of ihe administrator's 
terminal, as well as an e-mail message, page or lelephone 
call to the adminisira'.or. The administrator can manually 
intervene with the security procedure module to manually 
selec: updates ;o the var.o.is policies. Security incident 
reports, can be logged on a local database 1346. 

After reading I his description, it will become apparent to 
0:1c of ordinary sk.ll in the art how lo implement the 
functionality of the invention utilizing alternative architec- 
tures to thai described with reference to FIG. 13. For 
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example, the functionality of collection agent 1340 and 
detection engine 1342 can be delegated to one or more audit 
modules 1304 in the networked computing environment. 
This decentralized collection and detection may be prefer- 
able in certain computing applications. Although other func- 
lionalitv of security procedure module 1308 can be decen- 
tralized and delegated to one or more audit modules 1304, 
it is preferable that this functionality be centralized such that 
a single point of control can be implemented for the net- 
worked computing environment. Also, as stated above, in a 
preferred embodiment each computing resource in the net- 
worked computing environment includes an audit module 
1304 to track activities occurring at that resource. Security 
procedure module 130X may be implemented on a dedicated 
securilv console 10415 or other dedicated computing 
resource, or alternatively can be implemented on a comput- 
ing resource thai also performs additional or alternative 
functions within the network computing environment. 

Hie various embodiments of the invention described 
above may be implemented using hardware, software or a 
combination thereof and may be implemented in a computer 
svstem or other processing system. In fact, in one embodi- 
ment these elements are implemented using a computer 
system capable of carrying out the functionality described 
with respect thereto. 

PIG. 14 is a block diagram illustrating another example 
architecture for a security system for a computing environ- 
ment according to one embodiment of the invention. The 
architecture illustrated in PIG. 14 includes the functionality 
for creating and implementing security procedures as well as 
the functionality for delecting security occurrences and 
updating the implemented security procedures in response to 
detected occurrences. The architecture illustrated in FIG. 14 
includes a security profile 1404, audit settings 140S, and an 
event log 1410. In one embodiment, these elements are 
distributed such that they are resident on one or more of 
tartlet computers 1 04 A in a computing environment. In an 
alternative embodiment, one or more of these elements can 
be central i/.cd at one or more security consoles 104 U. 

Security profile 1404 is a profile of the security of target 
104A. Security profile can give an overall security standing 
for a ta me l 1 04 A as well as security posture for one or more 
attributes or characteristics of the target 104 A. for example, 
attributes such as number of unsuccessful log -on attempts 
allowed, password aging, password length, and other set- 
tings or characteristics can each be rated with a security 
posture (e.g.. poor, fair, good, very good, excellent). In one 
embodiment, these individual ratings can be combined to 
form an overall rating. 

Audit set'.iivjs 1408, in one embodiment, are the sellings 
established b\ :he audit policy. These can incl'.ide. lor 
example, sel'.inns for svstem audits, object audits, and other 
audits. The audit sellings 140S. which reiled -he audit 
policv, define or dic'.ale wha; events are logged in event log 
1410. In one embodiment. l:ie events are logged with an 
indication of '.he date and lime of the even: occurrence, die 
source of '.he e^eill. ar.cl a category of the type of eveili. The 
source can include the computer 104 associated with the 
event or the user associated with the even: or both. Catego- 
ries can include, for example, system events, log-oil related 
events. unaulhori/ed access al tempi events, and so on. As 
will be apparent to one of ordinary skill in the art, event 
categories can be created or defined for individual environ- 
ments to best indicate types of events logged. 

Also illustrated in I H i. 14 is an ageiv. 1420. In one 
embodiment, agent 1420 is resident on each target computer 
1 04 A. Agent 1420 can be used to update the audit settings 
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for the audit policy, as well as to facilitate the collection of 
events from event log 1410. Agent 1420 can also be used to 
retrieve information from security profile 1404 as well as to 
update security profile 1404. 

5 In ihe embodiment illustrated in PIG. 14, the security ^ 
system also includes centralized features, preferably pro- 
vided in a centralized capacity at a security workstation. 
Included with these centralized features can be a raw event 
log archive 1432. Raw event log archive 1432 is an archive 

to of events collect from one or more event logs 1410 at one or 
more targets 104A. As staled above, in one embodiment, 
events are collected from event log 1410 based on a collec- 
tion policv. Thus, raw event log archive 1432 can be 
considered as a data archive containing eveni logs from the 

15 various targets 104 A. In one embodiment, each event also 
has a field indicating the target 1 04 A from which is was 
received, and a field indicating Ihe user associated with an 
even I where applicable. 

Detection mechanism 1434 evaluates events in raw event 

:>i archive 1432 to determine whether a security occurrence or 
incident has occurred. If a security occurrence is delected, 
alert manager 1436 is notified such thai the administrator 
can Ix; alerted and appropriate responses put into effect. One 
response may be to immediately inform the agent 1420 

:5 associated wiih the a Heeled target to shut down the system 
or to log oil' the user. 

In one embodiment, security occurrences brought to the 
attention of alert manager 1436 can have an effect on the 
security posture in security profile 1404. For example, the 

M) security occurrence can result in alert manager 1436 down- 
grading the security rating of Ihe associated target 104 A. 

In one embodiment, the downgrading of the security 
rating in a security profile 1404 is fed back to an assessment 
manager 1444. The downgrading can occur as a result of 

.*5 changes to target 104A sensed by security profile 1404, or by 
the agent 1420 downgrading ihe rating. Assessment manager 
1444 evaluating ihe security posture of a target 104A may 
determine thai one or more of the security procedures need 
lo be updated to improve the security posture of the affected 

40 target 104A. Ilius, assessment manager 1404 may inform a 
target manager 1446 to update the security procedures for 
the a Heeled target 104A. 

T his can include an update of the audit policy 904 and the 
collection policy 912 to provide more frequent and/or more 

-is thorough audits of the activities associated with that largei 
104 A. In an alternative embodiment, alert manager 1436 
mav immediately notify target manager 1446 upon the 
detection of a security occurrence that the security proce- 
dures need io be updated. In this alternative, largei manager 

5<: 1446 can Like the steps necessary to update the security 
procedures appropriate ly. 

Also illustrated in PIG. 14 is an audit reduction 1438 
mechanism to reduce or distill .he audit records down to a 
useable set of audit data. This is data that is useful for the 

55 purpose** of archival or reporting and eliminates details thai 
irav :n-i *v ftes.red or necessary for dale archival or security 
reporting. The reduced ajtiit records are stored in a database 
1452 and made available for report generation 1454. As with 
the arc'ni'.eclure iih.siti.led in PIG. 13. the architecture illus- 

')■.< traied in PIG. 14 also provides for distributed functionality 
a i one or more targets 104A or associated with one or more 
users, as well as central i/ed functionality for detection of 
securitv occurrences and updating of security procedures. As 
slated above, the various functionalities described herein can 

>i5 be distributed in alternative architectures and it is not 
necessarv that each of :he functionaiities shown as bein^ 
distributed are, in fact, distributed in each embodiment, or 
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lhal the centralized functionality must he centralized. In fact, 
it will become apparent to one of ordinary skill in the art 
after reading this description that certain of these centralized 
functions can in fact he distributed among the targets 1 04 A 
depending, on the amount of processing requirements that a 
svstem designer chooses to olfload to various targets. 
Likewise, the distributed functions can be centralized with, 
perhaps, an increased requirement for communication 
between the centralized function and the associated targets 
104 A. 

RG. 15 is a block diagram illustrating a general purpose 
computer system, including examples of computer readable 
media for providing computer software or instructions to 
perform the functionality described herein. The illustrated 
computer system 1502 includes one or more processors, 
such as processor 1504. The processor 1504 is connected to 
a communication bus 1506. Various software embodiments 
are described in terms of this example computer system. 
After reading this description, it will become apparent to a 
person of ordinary skill in the relevant art how to implement 
the invent ion using other computer systems or computer 
architectures, including, for example, the architecture illus- 
trated in I'IG. I. 

Computer system 1502 also includes a main memory 
I50S, preferably Random Access Memory (RAM), and can 
also include a secondary memory 1510. 'Hie secondary 
memory 1510 can include, for example, a hard disk drive 
1512 and/or a removable storage drive 1514, representing a 
floppy disk drive, a magnetic tape drive, an optical disk 
drive, etc. Removable storage drive 1514 reads from and/or 
writes to removable storage media 1 528. Removable storage 
media 1528, represents a Happy disk, magnetic tape, optical 
disk, etc., which is read by and written to by removable 
storage drive 1514. As will be appreciated, the removable 
storage media 1528 includes a computer-usable storage 
medium having stored therein computer software and or 
data. 

In alternative embodiments, secondary memory 1510 may 
include oilier similar means for allowing computer programs 
or other instructions to be loaded into computer system 
1502. Such means can include, for example, a removable 
storage unit 1522 and a removable storage unit interface 
1520. Examples of such can include a program cartridge and 
cartridge interface (such as, for example, that found in video 
game devices), a removable memory chip (such as, for 
example, an E PROM, PROM or other memory device) and 
associated socket, and other removable storage units 1522 
and removable storage unit interfaces 1520 which allow 
software and data to be transferred from the removable 
storage unit 1522 lo computer system 1502. In some 
eir t h<x:imeiits. rur.ovah.e storage uni: 1522 m.t\ lie al:l\ed 
permaneir.ly to removable storage unit interface 1520. 

t'ompuier s est em 1502 can also inch: tie a com muni ca- 
tions interface 1524. Communications interface 1524 allow* 
software and data to be transferred between computer sys- 
tem 151)2 ar.d externa! devices, lixamples ^"communica- 
tions interface 1524 can include a modem, a network inter- 
face (such as an lit heme; card), a communications port, a 
PCMCIA slot and card. etc. Software and data transferred 
via c\ -m nrar.ica l ioii> interface 1524 are ir, the form of signals 
which can be electronic, electromagnetic, optical or oilier 
signals capable of being received by e<ir.iir.iinicalioi> inter- 
face 1524. These signals are provided to comnvjniea'.ions 
interface 1524 via a channel 152N. This channel 152S carries 
Simla's and can be implemented using a wireless medium, 
wire or cable, liber opiics. or other communications 
medium. Some examples of a channel can include a phone 
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line, a cellular phone link, an RF link, a network, the 
Internet, and other communications channels. 

In this document, the terms "computer program medium" 
and "computer usable medium" are used to generally refer 

5 to media such as removable storage media 1528, a hard disk 
installed in hard disk drive 1512, removable storage unit 
1522 and signals on channel 1528. These terms can also 
refer to main memory 1508 where main memory 1508 stores 
a computer program or a part thereof. These computer 

i0 program products are means for providing software to 
computer system 1502. 

Computer programs or instructions (also called computer 
control logic) can lie stored in main memory 1508 and/or 
secondary memory 1510. Computer programs can also be 
received via communications interface 1524. Such computer 

15 programs, when executed, enable the computer system 1502 
to perform the features of the present invention as discussed 
herein. In particular, the computer programs, when 
executed, enable the processor 1504 to perform the features 
of the present invention. Accordingly, such computer pro- 

:o grams represent controllers of the computer system 1502. 
In an embodiment where the elements are implemented 
usiiiL; software, the software may be stored in a computer 
program product and loaded into computer system 1502 
using removable storage drive 1514, removable storage unit 

1;! 1522, hard drive 1512 or communications interface 1524. 
'ITie control logic (so ft ware), when executed by the proces- 
sor 1504, causes the processor 1504 to perform the functions 
of the invention as described herein. 

In another embodiment, the elements are implemented 

, () primarily in hardware using, for example, hardware com- 
ponents such as Application Specific Integrated Circuits 
(ASICs). Implementation of the hardware state machine so 
as to perform the functions described herein will be apparent 
lo persons of ordinary skill in the relevant art(s). Although 
not a "computer program" in the traditional sense, the 
hardware components can be thought of as a computer 
program medium (albeit, perhaps hard -wired) which enables 
the system to perform the described functions. In yet another 
embodiment, elements are implemented using a combina- 

40 lion of both hardware and software. In this embodiment, the 
combination of the hardware and software can likewise be 
thought of as a computer program medium that enables the 
system to perform the described functions. 
n . Conclusion 

45 While various embodiments of the present invention have 
been described above, it should be understood lhal they have 
been presented by way of example only, and not limitation. 
Thus, the breadth and scope of the present invention should 
not be limited by any of the above -de scribed exemplary 
embodiments, but should he defined only in accordance with 
the following claims ;md :heir equivalents. 
What is c-a.nied is: 

1. A system f.>r managing security occurrences in a 
networked compu'.ing environment having one or more 
large; compu'.ing n\mui*.s. comprising: 

r.ieai^ tor dclining security procedures in the network 
computing cnwivumcrx wherein said security proce- 
dures include an ai.dil policy, a col led ion policy, a 
delect ion p. iic\. .n:d a security policy; 
t,. ; r.K-ans for implementing said delined security procedures 
at said one or more target computing systems 
a la rue I agent associated with said one or more target 
coinpaiini; systems, said target agent being configured 
;o monitor activities in a networked computing envi- 
v ronment in accordance w ith said security procedures 
ar.d to tra.'ii'.a.n records of said activities in a local 
event log tile: 
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a detection engine configured 10 collect said activities 
from said target agent and to determine whether a 
security occurrence is occurring hased on said collected 
activities; and 

a respon.se service configured to update said security ^ 
procedures in response to a detected security incident; 

wherein said means for implementing said defined secu- 
rity procedures is further configured to implement said 
updated security procedures. 

2. The system of claim 1, wherein said updated security 10 
procedures comprise an updated collection policy. 

3. The system of claim 1. wherein said updated security 
procedures comprise an updated audit policy. 

4. fhe system of claim 3, wherein the audit policy- 
comprises an identification of files to he audited. > 

5. The system of claim 4, wherein the idem if cat ion of the 
tiles to he audited comprises an identification of at least 
some of '.he tiles to he audited using wild cards. 

6. A method for managing security incidents in a com- ^ 
puling environment, comprising: 

defining security procedures, wherein said security pro- 
cedures include one or more policies; 

implementing said security procedures on one or more 
computing systems in the computing environment; :> 

detecting a security incident using said implemented 
security procedures; 

updating said security procedures in response to said 
detected security incident; and 

implementing said updated security procedures on at least 
one of said one or more computing systems; 

wherein said one or more security procedures comprise at 
least one of a security policy, an audit policy, a collec- 
tion policy and a detection policy. 

7. The method of claim 6, wherein said step of updating 
said securitv procedures comprises the step of incrementing 
a level of one or more policies that make up said security 
procedu res. 

8. The method of claim 6, wherein said step of updating J() 
said securitv procedures comprises the step of increasing to 

a max i mum a level of one or more policies that make up said 
security procedures. 

9. The method of claim 6, wherein said step of imple- 
menting said updated security procedures comprises the step 4 . 
of implementing said updated security procedures for an 
identified user or group of users. 

10. The method of claim 6. wherein said step of detecting 
a security incident comprises the steps of: 

monitoring activities on one or more computing systems 
in the computing environment in accordance ur.h said 
security procedures; and 
determining whether said monitored activities exceed a 

predefined '.e\'el of acceplahili'.v 
1.1. The method ol claim 1 0. wherein sa id step o:\ielecling 55 
a ^eour.ty incident further comprises t:ie step ..!' determining 
a user or 'jjoup of users associated w:ih the security incident 
are ident. lied. 

12. fhe method of claim 10. wherein, said skp of delect- 
ing a security incident further comprises the step of deter- <vj 
I'liininu a tvpe of hreach or potential breach. 

13. The method of claim 10. wherein said step of deler- 
minin.H comprises the step of analyzing patterns of activities 
for particular users. 

14. The method of claim 10. wherein said step of deter- '>5 
minim: comprises the step of determining whether a :u:mher 

of monitored occurrences exceeds a predefined limit. 
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15. 'The method of claim 6. wherein said step of detecting 
a security incident further comprises the step of notifying an 
administrator of the security incident. 

16. The method of claim 6, wherein said updated security 
procedures comprise an updated collection policy. 

17. The method of claim 6. wherein said updated security 
procedures comprise an updated audit policy. 

18. The method of claim 17. wherein the audit policy 
comprises an identification of files to he audited. 

19. The method of claim 18, wherein the identification of 
the tiles to he audited comprises an identification of at least 
some of the tiles to he audited using wild cards. 

20. A system for managing security incidents in a com- 
puting environment, comprising: 

a security system configured to define and implement 
security procedures in the computing environment; 

a detection system conligurcd to detect security incidents 
in the computing environment in accordance with said 
security procedures; and 

a response system configured to update said security 
procedures in response to a detected security incident 
and to cause said security system to implement said 
updated security procedures in the computing environ- 
ment; 

wherein said security procedures comprise at least one of 
a security policy, an audit policy, a collection policy 
and a detection policy. 

21. The system of claim 20, wherein said updated security 
procedures comprise an updated collection policy. 

22. The system of claim 20, wherein said updated security 
procedures comprise an updated audit policy. 

23. The system of claim 22, wherein the audit policy 
comprises an identification of files to he audited. 

24. The system of claim 23, wherein the identilieaiion of 
the liles to he audited comprises an identification of at least 
some of I he tiles to Ix 1 audited using wild cards. 

25. A system for managing security incidents in a com- 
puting environment, comprising: 

means for defining security procedures, wherein said 
securitv procedures include one or more policies; 

means for implementing said security procedures on one 
or more computing systems in the computing environ- 
ment; 

means for detecting a security incident using said imple- 
mented security procedures; 

means for updating said security procedures in response 
to said delected security incident; and 

means tor implementing said updated security procedures 
or. least (.me of said one or more computing systems; 

wherein said one or more policies comprise at least one of 
.t securitv policy, an audit policy, a collection policy 
.u:d a detection p -lies. 

2d. The -Astern ol claim 25. wherein said updated security 
pro^d'.ires comprise an uxia'.ed collection policy. 

27. The svsteir. ol claim 25. wherein said updated security 
procedures eompri-e an updated audit policy. 

28. The system of cd;in; 27. wherein the audit policy 
comprises an identification of liles to he audited. 

2*J. file svslem of cla;ir. 28. wherein the identilieaiion of 
the files io he audited comprises an identification of at least 
some of the liles to audited using wild cards. 

30. A computer program medium emhodying a program 
of instructions for causing a computer system to perform 
method steps ol' managing security incidents in a computing 
environment, said method steps comprising the steps of: 
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clc lining security procedures, wherein said security pro- 
cedures include one or more policies; 
implementing said security procedures on one or more 

computing systems in the computing environment; 
detecting a security incident using said implemented 

security procedures; 
updating said security procedures in response to said 

detected security incident: and 
implementing said updated security procedures on at least 1( j 

one of said one or more computing systems; 
wherein said one or more policies comprise at least one ol 

a security policy, an audit policy, a collection policy 

and a detection policy. 

31 . The computer program medium of claim 30. wherein 15 
said updated security, procedures comprise an updated col- 
lection policy. 

32. The computer program medium o!' claim 30. wherein 
said updated security procedures comprise an undated audit 
policy. 

33' The computer program medium of claim 32, wherein 
the audit policy comprises an identification ol' tiles to be 
a udiled. 

34. The computer program medium of claim 33. wherein 
the identification of the liles to be audited comprises an :> 
identification of at least some of the liles to be audited using 
wild cards. 

35. A system for managing security incidents in a com- 
puting environment which comprises one or more comput- 
ing systems, said system comprising: .*0 

means for implementing security procedures in said com- 
puting environment; 

means lor detecting a security incident using said imple- 
mented security procedures; 

means for updating said security procedures in response 
to said detected security incident; and 

means lor implementing said updated security procedures 
on at least one of said one or more computing systems; 
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wherein said implemented security policies comprise at 
least one of a security policy, an audit policy, a collec- 
tion policy and a detection policy. 

36. The system of claim 35, wherein said updated security 
procedures comprise an updated collection policy. 

37. The svsiem of claim 35, wherein said updated security 
procedures comprise an updated audit policy. 

38. The system of claim 37, wherein the audit policy 
comprises an identification of liles to be audited. 

39. The system of claim 3S, wherein the identification of 
the liles to be audited comprises an identification of at least 
some of the liles 10 be audi led using wild cards. 

40. A system for managing security occurrences in a 
network computing environment having one or more target 
computing systems, comprising: 

means for defining security procedures in the network 
computing environment, wherein said security proce- 
dures include at least oix- of a security policy, an audit 
no I icy, a collection polic\ and a detection policy; 

means for implementing said de lined security procedures 
at said one or more target computing systems 

;in lari^et agent associated with said one or more target 
computing systems, said target agent being configured 
to monitor network activities in accordance with said 
security procedures and to maintain records of said 
network activities in a local event log file; 

a detection engine configured to collect said network 
activities from said target agent and to determine 
whether a security incident is occurring based on said 
collected network activities; and 

a response service configured to update said security 
procedures in response to a detected security incident; 

wherein said means for implementing said defined secu- 
rity procedures is further configured to implement said 
updated security procedures. 

T * + * * 
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